引言：被遺忘的 PDF 與 AI 治理的真相

在推動企業數位轉型的過程中，我見過無數完美的 AI 專案計畫。團隊花費數週討論評估矩陣、定義嚴謹的邊界表，但這些心血最終往往落得「寫完即丟」的下場。一旦這些文件被存成 PDF 放入資料夾，就成了無人問津的數位遺體。

我們必須意識到一個殘酷的真相：文件若無法自動執行，治理就無法落地。 如果治理只存在於紙面上，風險就會持續潛伏在系統中。為了打破這個僵局，我們需要將抽象的規範直接轉化為可運行的系統設施——這就是建立「AI 任務登錄台」的核心目標。

核心觀念一：AI 任務的「戶口名簿」——如果不登錄，就等於不存在

「AI 任務登錄台」是 BAIOS（AI 治理中台）第一個可執行的模組，它確立了一條不容挑戰的鋼鐵紀律：「任務未登錄，不得進入開發。」

目前許多企業的 AI 應用現狀是「散落各處」：某個分類提示詞（Prompt）可能在 A 同事的記事本裡，檢核腳本在 B 同事的桌面，主管甚至無法準確回答單位內究竟有多少個 AI 應用在跑。這種黑盒狀態是合規最大的敵人。

參考「保險業自律規範」，有效的管理必須建立在三大前提之上：風險基礎的定期檢視（§4）、了解 AI 運作方式（§9 IV）、以及確保軌跡紀錄可供查驗（§5）。要達成這些要求，你必須先擁有一份「AI 任務的戶口名簿」，讓每一個 AI 任務從誕生之初就具備合法的「數位身份」。

核心觀念二：治理規則的自動化——讓程式碼替你把關

要讓治理真正落地，最好的方式就是將規範寫進程式碼。在登錄台 v0.2 版本中，我們利用 Pydantic 資料模型與驗證器（Validator），將原本抽象的治理欄位轉化為強制性的技術約束。

這不僅僅是增加欄位，而是內建了治理邏輯。例如，當任務被標註為「高風險」時，系統驗證器會強制要求更短的複審週期（例如每月複審一次），而非高風險任務則可設定較長週期。這種「硬約束」確保了高風險應用不會因人為疏忽而漏掉檢視。

在設計思維上，這背後有一個深刻的涵義：「填不出已知限制的任務，就是還沒想清楚的任務。」 透過驗證器，我們能確保所有不合規、思考不周全的資料根本無法存入系統。治理，從資料存檔的那一刻就開始了。

技術洞見：稽核留痕的藝術——只進不改的 JSONL

在儲存層設計上，我們將「當前任務狀態（tasks.json）」與「歷史稽核紀錄（audit_log.jsonl）」完全分離。

「稽核紀錄的第一原則是只進不改。」

這段金句不僅是技術選擇，更是法律合規（如 §5 軌跡紀錄要求）的最低防線。我們刻意採用 JSONL（JSON Lines）格式，以「追加（Append）」而非覆寫的方式記錄每一筆異動。

更關鍵的細節在於「變動偵測」。系統在更新任務時，會自動比對新舊欄位的差異。只有當資料確實發生變動時，才會寫入包含「變動欄位清單」的稽核紀錄。這能精確追蹤是誰在何時修改了「模型選用理由」或「複審週期」，同時避免產生大量「存了但沒改」的冗餘垃圾紀錄，確保稽核路徑（Audit Trail）的純淨與真實。

溝通橋樑：模型使用說明卡——讓業務負責人讀懂 AI

技術文件與業務決策之間通常存在巨大的鴻溝。為了強化企業內的責任鏈，登錄台會根據治理欄位自動生成 Markdown 格式的「模型使用說明卡」。

這份說明卡將複雜的技術參數轉譯為業務負責人（Business Owner）簽核前必須讀懂的語言，內容包含：

• 運作摘要：用三句話清楚解釋 AI 正在做什麼。
• 已知限制與禁止事項：明確界定應用的邊界，防止誤用。
• 驗收指標與複審狀態：包含逾期偵測警示，讓負責人一眼看出該應用是否仍受控。

這確保了業務負責人在簽名時，不是在簽一份看不懂的技術備忘錄，而是真正理解並承擔該 AI 應用的運作責任。

實務教訓：測試的重要性——預防那些「寫程式當下」發現不了的錯

在實作過程中，我們遭遇了一個經典的失敗：序列化錯誤（Serialization Error）。

第一版儲存層直接使用原生 json.dumps 處理 Pydantic 物件。在撰寫程式碼時，語法完全正確，IDE 也沒報錯，直到第一次嘗試存檔時系統才崩潰——因為原生 JSON 庫無法處理 date 物件（日期）與 Enum（列舉）。

「這種錯不會在寫程式的當下被發現……直到第一次真的存檔。」

作為專家，我的解決方案是全面改用 Pydantic 的 JSON 模式（model_dump_json），它能自動優雅地處理日期與型別轉換。另一個實務小坑是 Streamlit 的自動頁面導覽功能，會干擾預設的目錄結構，我們必須透過 .streamlit/config.toml 關閉自動導覽才能保住結構的嚴謹性。

這些細節再次證明了 pytest 單元測試 的價值。我們的版本號從 v0.2 起跳，正是體現了「設計誠實」：v0.1 的直覺設計在面對真實治理需求與技術實作時，往往是不及格的。

結語：從管理到實戰的跨越

今日，我們不再只是討論概念，而是產出了實打實的治理設施：

1. 任務登錄台 v0.2：落實「不登錄、不開發」與高風險強制複審。
2. 自動化稽核機制：變動留痕且不可竄改。
3. 模型使用說明卡產生器：搭起業務與技術的信任橋樑。
4. 21 個單元測試：包含例外情境測試（如重複編號、查無任務、格式錯誤等），確保系統防爆。

下一階段，我們將進入真正的實戰：將治理指標應用於「公用信箱需求分類」任務，把抽象的治理指標轉化為實測的準確率。

最後，留下一個問題供你反思：當你的 AI 應用出錯時，你是否有足夠的「軌跡紀錄」證明你的治理是玩真的，還是只是存放在資料夾裡的 PDF？